Digital messaging (e.g., e-mail, text messages, etc.) is an essential network service. Many digital messaging systems that send digital messages over the Internet use protocols such as simple mail transfer protocol (SMTP), in the case of e-mail, and other protocols when the digital message is other than e-mail, to send digital messages from one server to another. The messages can then be retrieved with a client using services such as post office protocol (POP) or Internet message access protocol (IMAP). Other protocols for sending digital messages that are e-mails include, but are not limited to, POP3, X.400 International Telecommunication Union standard (X.400), and the Novell message handling service (MHS), and extended simple mail transfer protocol (ESMTP). Specifically, X.400 defines a transfer protocol for sending electronic mail between mail servers and is used in Europe as an alternative to SMTP. MHS, which was developed by Novell, is used for electronic mail on Netware networks.
SMTP transports digital messages among different hosts within the transmission control protocol/Internet protocol (TCP/IP) suite. Under SMTP, a client SMTP process opens a TCP connection to a server SMTP process on a remote host and attempts to send mail across the connection. The server SMTP listens for a TCP connection on a specific port, usually port 25, and the client SMTP process initiates a connection on that port. When the TCP connection is successful, the two processes execute a simple request-response dialogue, defined by the SMTP protocol (see RFC 821 STD 10, simple mail transfer protocol, August 1982, for details), in which the client process transmits the mail addresses of the originator and the recipient(s) for a message. When the server process accepts these mail addresses, the client process transmits the e-mail instant message. The e-mail message contains a message header and message text (“body”) formatted in accordance with RFC 822 (RFC822 STD 11, Standard for the format of ARPA—Internet Text Messages, August 1982). Mail that arrives via SMTP is forwarded to a remote server or it is delivered to mailboxes on the local server. On UNIX-based systems, Sendmail is a widely used SMTP server for e-mail. Sendmail includes a POP3 server and also comes in a version for Windows NT. Microsoft Outlook is the most popular mail-agent program on Window-based systems. Similar protocols are used when the digital message is other than e-mail.
The SMTP model (RFC 821) supports both end-to-end (no intermediate message transfer agents “MTAs”) and store-and-forward mail delivery methods. The end-to-end method is used between organizations, and the store-and-forward method is chosen for operating within organizations that have TCP/IP and SMTP-based networks. A SMTP client will contact the destination host's SMTP server directly to deliver the mail. It will keep the mail item from being transmitted until it has been successfully copied to the recipient's SMTP. This is different from the store-and-forward principle that is common in many other electronic mailing systems, where the mail item may pass through a number of intermediate hosts in the same network on its way to the destination and where successful transmission from the sender only indicates that the mail item has reached the first intermediate hop. The RFC 821 standard defines a client-server protocol. The client SMTP is the one which initiates the session (that is, the sending SMTP) and the server is the one that responds (the receiving SMTP) to the session request. Because the client SMTP frequently acts as a server for a user-mailing program, however, it is often simpler to refer to the client as the sender-SMTP and to the server as the receiver-SMTP. A SMTP-based process can transfer electronic mail to another process on the same network or to another network via a relay or gateway process accessible to both networks. An e-mail message may pass through a number of intermediate relay or gateway hosts on its path from a sender to a recipient.
A simple model of the components of the SMTP system is shown in FIG. 1. Systems that send digital messages other than e-mail have similar components. Referring to FIG. 1, users deal with a user agent (UA). Popular user agents for UNIX include Berkeley Mail, Elm, MH, Pine, and Mutt. The user agents for Windows include Microsoft Outlook/Outlook Express and Netscape/Mozilla Communicator. The exchange of e-mail using, for example TCP, is performed by an MTA. One MTA for UNIX systems is Sendmail, and a conventional MTA for Windows is Microsoft Exchange Server 2007. Users normally do not deal with the MTA. It is the responsibility of the system administrator to set up the local MTA. Users often have a choice, however, for their user agent. The local MTA maintains a mail queue so that it can schedule repeat delivery attempts in case a remote server is unable. Also the local MTA delivers mail to mailboxes, and the information can be downloaded by the UA (see FIG. 1). The RFC 821 standard specifies the SMTP protocol, which is a mechanism of communication between two MTAs across a single TCP connection. The RFC 822 standard specifies the format of the electronic mail message that is transmitted using the SMTP protocol (RFC 821) between the two MTAs. As a result of a user mail request, the sender-SMTP establishes a two-way connection with a receiver-SMTP. The receiver-SMTP can be either the ultimate destination or an intermediate one (known as a mail gateway). The sender-SMTP will generate commands, which are replied to by the receiver-SMTP (see FIG. 1).
A typical e-mail delivery process is as follows. Delivery processes for digital messages other than e-mail follow similar scenarios. In the following scenario, Larry at terminal 102 sends e-mail to Martha at her e-mail address: martha@example.org. Martha can review here e-mail at terminal 102. Martha's Internet Service Provider (ISP) uses mail transfer agent MTA 106.
1. Larry composes the message and chooses send using mail user agent (MUA) 108. The e-mail message itself specifies one or more intended recipients (e.g., destination e-mail addresses), a subject heading, and a message body; optionally, the message may specify accompanying attachments.
2. MUA 108 queries a DNS server (not shown) for the IP address of the local mail server running MTA 110. The DNS server translates the domain name into an IP address, e.g., 10.1.1.1, of the local mail server.
3. User agent 108 opens an SMTP connection to the local mail server running MTA 110. The message is transmitted to the local mail server using the SMTP protocol. An MTA (also called a mail server, or a mail exchange server in the context of the Domain Name System) is a computer program or software agent that transfers electronic mail messages from one computer to another. Webster's New World Computer Dictionary, tenth edition, Wiley Publishing Inc., Indianapolis, Ind., defines an MTA as an e-mail program that sends e-mail messages to another message transfer agent. An MTA can handle large amounts of mail, can interact with databases in many formats, and has extensive knowledge of the many SMTP variants in use. Examples of high-throughput MTA systems are disclosed in U.S. patent application Ser. No. 10/857,601, entitled “Email Delivery System Using Metadata,” filed May 27, 2004 as well as U.S. patent application Ser. No. 10/777,336, entitled “Email Using Queues in Non-persistent memory,” filed Feb. 11, 2004, each of which is hereby incorporated by reference in its entirety. One example of an MTA system is the StrongMail MTA (Redwood Shores, Calif.). Conventional MTA programs include, but are not limited to, Sendmail, qmail, Exim, Postfix, Microsoft Exchange Server, IMail (Ipswitch, Inc.), MDaemon (Alt-N Technologies), MailEnable, Merak Mail Server, and qmail.
4. MTA 110 queries a DNS server (not shown) for the MX record of the destination domain, e.g., example.org. The DNS server returns a hostname, e.g., mail.example.org. MTA 110 queries a DNS server (not shown) for the A record of mail.example.org, e.g., the IP address. The DNS server returns an IP address of, for example, 127.118.10.3.5. MTA 110 opens an SMTP connection to the remote mail server providing e-mail service for example.org which is also running MTA 106. The message is transmitted to MTA 106 from MTA 110 using the SMTP protocol over a TCP connection.
5. MTA 106 delivers Larry's message for Martha to the local delivery agent 112. Local delivery agent 112 appends the message to Martha's mailbox. For example, the message may be stored in (e.g., using a sample file path on a UNIX system): /var/spool/mail/martha.
6. Martha has her user agent 114 connect to her ISP. Martha's user agent 114 opens a POP3 (Post Office Protocol version 3, defined in RFC1725) connection with the POP3 (incoming mail) server 112. User agent 114 downloads Martha's new messages, including the message from Larry.
7. Martha reads Larry's message.
The MTA 110, which is responsible for queuing up messages and arranging for their distribution, is the workhorse component of electronic mail systems. The MTA “listens” for incoming e-mail messages on the SMTP port, which is generally port 25. When an e-mail message is detected, it handles the message according to configuration settings, that is, the settings chosen by the system administrator, in accordance with relevant standards such as Request for Comment documents (RFCs). Typically, the mail server or MTA must temporarily store incoming and outgoing messages in a queue, the “mail queue.” Actual queue size is highly dependent on one's system resources and daily volumes.
In some instances, referring to FIG. 2, communication between a sending host (client) and a receiving host (server), could involve relaying. In addition to one MTA at the sender site and one at the receiving site, other MTAs, acting as client or server, can relay the electronic mail across the network. This scenario of communication between the sender and the receiver can be accomplished through the use of a digital message gateway, which is a relay MTA that can receive digital messages prepared by a protocol other than SMTP and transform it to the SMTP format before sending it. The digital message gateway can also receive digital messages in the SMTP format, change it to another format, and then send it to the MTA of the client that does not use the TCP/IP protocol suite. In various implementations, there is the capability to exchange mail between the TCP/IP SMTP mailing system and the locally used mailing systems. These applications are called digital message gateways or mail bridges. Sending digital messages (e.g., e-mail) through a digital message gateway may alter the end-to-end delivery specification, because SMTP will only guarantee delivery to the mail-gateway host, not to the real destination host, which is located beyond the TCP/IP network. When a digital message gateway is used, the SMTP end-to-end transmission is host-to-gateway, gateway-to-host or gateway-to-gateway; the behavior beyond the gateway is not defined by SMTP.
Due to their convenience and popularity, e-mails have become a major channel for communications amongst individuals and businesses. Since e-mails can be used to reach a much wider audience in a short period of time, e-mails have also been utilized regularly as a tool in marketing campaigns. There are a number of e-mail marketing companies which have established a market for tracked e-mail campaigns. These companies provide feedback to the e-mail sender when an e-mail was opened by its intended recipient. In some instances, this is accomplished via the inclusion of a ‘web beacon’ (or a single-pixel gif) which is uniquely coded and linked to the particular recipient of the e-mail. In some instances, in order to generate and send e-mails for a tracked campaign, an end user goes through a multi-step workflow that typically includes: (1) recipient list creation/selection—loading into a mass-mail tool a list of possible recipients and creating a recipient list containing selected recipients for a particular campaign; (2) template authoring—using the mass-mail tool to author the HTML email according to one or more predefined templates; and (3) mail merge and execution (send)—merging the recipient list into the predefined templates, thereby creating separate e-mails which contain unique tracking codes in the form of references to an image on a remote server. These e-mails are then sent by a mail bursting engine. When the recipient opens the e-mail in an HTML-enabled e-mail client, the e-mail client contacts the remote server to retrieve the desired image. Because each image is uniquely coded, the remote server is able to track when the e-mail intended for a particular recipient was opened.
Methods for optimizing e-mail marketing campaigns are available. For example, United States Patent Publication No. 2006/0253537 A1 to Thomas (hereinafter, “Thomas”) discloses a method for sending a marketing message in the form of an e-mail to recipients, electronically tracking at least one selected response event occurring as the e-mail is being sent to targeted recipients, and automatically modifying the e-mail that is subsequently sent to targeted recipients in the campaign by changing elements in the e-mail based upon the tracked selected response event. The drawback with this method is that it does not dynamically determine which variables affect the success of an e-mail campaign. Consider a scenario in which the target is to maximize the percentage of time the sent e-mail is opened by recipients. Does the age of the recipients affect this target? Does what appears on the subject line affect this target? Is there some interdependence between age and what is on the subject line that affects this target? Thomas simply does not address these questions. In fact, Thomas makes no effort whatsoever to dynamically segment the recipient population and optimize what is sent to each portion of the recipient population.
In another example, U.S. Pat. No. 7,130,808 B 1 to Ranka et al. (hereinafter Ranka) discloses a method for reading a prior stage message state pertaining to a prior stage in a message campaign, reading message performance results representing message trials and message successes from the prior stage, computing a current message state on the basis of the prior stage message state and the message performance results, and generating a current message allocation based on the current message state. As in the case of Thomas, the drawback with Ranka is that it does not dynamically determine which variables affect the success of an e-mail campaign. As in the case of Thomas, consider a scenario in which the target is to maximize the percentage of time the sent e-mail is opened by recipients. Does the age of the recipients affect this target? Does what appears on the subject line affect this target? Is there some interdependence between age and what is on the subject line that affects this target? Ranka, like Thomas, simply does not address these questions. In fact, Ranka makes no effort whatsoever to dynamically segment the recipient population and optimize what is sent to each portion of the recipient population.
Given the above background, what is needed in the art are improved systems and methods for optimizing e-mail campaigns.
Discussion or citation of a reference herein will not be construed as an admission that such reference is prior to the present disclosure.